home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_0799 / 717 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.3 KB
  1. Date: Thu, 16 Dec 93 20:01:49 MST
  2. From: shenson@nyx10.cs.du.edu (Stephen Henson)
  3. Message-Id: <9312170301.AA21349@nyx10.cs.du.edu>
  4. X-Disclaimer: Nyx is a public access Unix system run by the University
  5.     of Denver.  The University has neither control over nor
  6.     responsibility for the opinions or correct identity of users.
  7. To: mint@terminator.rs.itd.umich.edu
  8. Subject: Updates and things ...
  9.  
  10. Greetings,
  11.           the Minixfs updater does one single Dcntl for MFS_SYNC. This
  12. function is analagous to Unix sync() in that all drives are handled at
  13. once. The reason for the path is because there is no way to send info
  14. to a fileystem without a path of an 'owned' drive. However the update
  15. demon needs access to Minixfs internals to be sure of finding the
  16. drive and avoiding diskette whirring (which is caused by the calling of
  17. routines which determine the filesystem and by the brain damaged hardware
  18. which kludges disk changes of write protected drives). This sync operation
  19. also cannot be interrupted by a context switch, so the update daemon is
  20. run as a user process which makes a syscall.
  21.  
  22. [side note, from the above, you only need call MFS_SYNC once to sync all          
  23. filesystems (on the first filesystem MFS_VERIFY returns the right magic
  24. number). The preferred method though is sending anything other than
  25. SIGSTOP and SIGKILL to the update process, this avoids whirring]
  26.           
  27.           This is not ideal, but the performance increase is so great that
  28. I felt that some method compatible with the various older MiNT's out there
  29. was more approprate than something which relied on a (possibly unofficial)
  30. kernel patch. Besides, I leave the kernel alone unless I have no choice.
  31.           If we want a single update process (or none at all) then I would
  32. suggest either a new entry in the FILESYS structure (sync?) which is called
  33. periodically, or some way of specifying an internal function to be called
  34. at periodic intervals. The latter is perhaps preferable because it allows
  35. more flexibility (you may not want all update processes to be called at
  36. the same interval). I'd certainly support this if it ever became 'official'.
  37.           Ah, one more thing, I can make the cache mode easily work on a
  38. 'per filesystem' basis, however I don't think it wise to make floppies
  39. permanently not use turbo mode; the performance loss is considerable.
  40.  
  41. Regards and Seasons Greetings, Steve.
  42.  
  43.  
  44.